A distributed system is, broadly speaking, an aggregate of individual systems that are connected via electronic communications. The separation of components inherent in a distributed system provides advantages over a tightly integrated system approach in allowing the truly parallel execution of programs, the containment of faults without system disruption, and the use of isolation and interlocks as security enforcement measures.
A LAN is a type of distributed system that loosely couples remote processors and workstations. Generally, workstations on a LAN do not share a central memory, but do share common servers such as one or more file servers, print servers, etc. High-speed LANs, in particular, effectively increase the power and flexibility of workstations (computers designed for one or more single users with sufficient processing power and memory to run users application programs) by enabling them to have access to shared data and resources located in their own and other server computers.
The LAN system that has been in the widest use in recent years is produced by Novell, Inc. of Provo, Utah. In a Novell system, a LAN device driver is implemented on top of the local operating systems to be coupled, and device driver commands (and responses) at the LAN workstations are directed from (and to) the workstations onto the LAN to (and from) the target servers.
As the users of personal computers and workstations, as well as minicomputers, mainframes and supercomputers, try to take better advantage of their combined resources, LANs are being grown with disparate (i.e., heterogeneous) systems made up of the variety of hardware, software and applications already installed.
However, network access and connectivity alone are not sufficient to perform useful work between disparate systems on a LAN. These components must have a common understanding of the particular type of work or application to interoperate. They must also utilise the same procedures to implement that type of work. One level of interoperability is to establish terminal emulation to access applications on other systems. Another option is to use a batch file transfer mechanism to transfer data to another machine, where a program will parse the data and perform work on it according to a pre-established protocol. Both of these mechanisms require system specific software that is not portable without modification, for connecting other types of hardware and/or operating systems.
One goal of developments in distributed systems is to develop means for providing interoperability that is more universal (portable to a larger number of computers and/or operating system types), while maintaining transparency (concealment of separation) to the user (whether that user is a machine or application). Ideally, the user should not be aware of accessing resources on remote servers in a LAN, but should perceive the system as a whole rather than as a collection of individual components.
In a homogeneous distributed system, such as the Novell Netware.sup.1 LAN, each separate computer has the same operating system and identical software hierarchy. In the Novell system, this is the Netware Asynchronous Service Interface (NASI). The LAN device driver contains facilities for communications between processes in separate computers. Again, in the Novell system, this is the Netware Asynchronous Communications Server (NACS). FNT .sup.1 Trademark of Novell, Inc.
The Distributed Computing Environment (DCE) of the Open System Foundation (OSF.sup.2) is a very recent emerging technology enabling distributed computing among heterogeneous systems. When implemented on each of the disparate systems, DCE allows transparent interoperation between computers on the LAN through a mechanism called the remote procedure call (RPC) that extends to the distributed environment the concept of a local procedure call, a well understood communications mechanism for constructing a program using subroutines (also called subprograms or procedures) within an operating system. The RPC mechanism is implemented in DCE in conjunction with a multi-threading capability similar to that described in the IEEE POSIX 1003.4a draft standard.sup.3. This combination permits RPC concurrency in the OSF DCE environment. FNT .sup.2 Trademarks of the Open Software Foundation FNT .sup.3 IEEE P1003.4a/D4 draft standard, Threads Extension for Portable Operating Systems, Technical Committee on Operating Systems of the Institute of Electrical and Electronic Engineers (IEEE) Computer Society, New York, N.Y., USA, Aug. 10, 1990.
Normally, in the absence of an RPC mechanism, there is a unique interface between the calling program and a specific subroutine, and the local procedure call invokes all necessary logic for operability. When the subroutine resides on a different machine than the calling program, communications logic (i.e., the location of the subroutine, data conversions, etc.) is required for the call and must be hard-coded into the calling and/or called programs.
In OSF's DCE, the RPC itself automatically invokes the communications services for the programmer, and all, or optionally almost all, communications code, error handling and data conversion are handled transparently, thereby removing concern for the communications mechanisms from the programs that use remote procedures.
In the DCE system, for each subroutine call, the RPC mechanism can automatically invoke a directory that provides naming and other support protocols for every resource in the network. Thus, application programs can make use of distributed services by issuing calls to remote procedures by name, without knowing their location(s). This provides location transparency, as the distributed system is completely configurable in terms of the location of its components. As described above, the RPC mechanism also permits heterogeneity in the DCE environment.
The increasing proliferation of remote electronic information exchange has made access to remote servers such as processors and databases a necessity. This access is often facilitated through circuit-switched communications links over wide area networks (WANs).
A useful description of a typical switched area network of this type is that found in U.S. Patent Nos. 4,896,319, 4,897,874 and 4,958,341, all to A T & T, that relate to a "metropolitan area network" (MAN). The switches described in these patents are similar to those typically used for WANs, although the protocols for the type of system specified appears to be directed to the secure transmission of data.
Typically, access to or from a remote machine across a WAN from (or to) a workstation on a LAN is gained by instituting a switched communications link through a LAN gateway server. A device driver for the gateway is provided with physical ports (or modems) that can be linked to switched communications WANs.
Existing gateway mechanisms, such as Novell's NACS and NASI, are generally implemented on top of the LAN device driver as a switched communications device interface and a LAN redirection facility on the workstation programming interface, and a corresponding LAN redirection facility and switched communications device interface implemented at the gateway, providing for both the transmission and receipt of switched communications links through the gateway modems. Redirections are also used for communicating serial port and modem commands between the gateway and other machines on the LAN.
In such systems, the user's initialization of the communications link-up procedure redirects the user hardware commands to the gateway. The communications interface in the gateway driver then institutes and maintains the switched communications link, diverting hardware resources of the driver to do so. An exclusive device driver access mode would typically be used in accessing the remote ports. The connection and access procedures are then executed using the gateway ports and modems ill order to link the user's system with the switched communications network. A remote connection is established through the WAN. This sets up a point-to-point configuration through the port along the communication line between the user computer and server computer, monopolizing the switched communications device in use.
The device driver interface is hardware-oriented, and imposes the restriction that the device drivers in the workstations and LANs support compatible LAN redirection facilities. These are generally not available in a heterogeneous system, with the result that most current LAN systems require that the computer and/or operating system at the workstations and the gateway be homogeneous.
Also, the LAN workstations are effectively in full control of the switched hardware ports at the gateway. This virtually eliminates the possibility of implementing any flexible automatic and transparent support for regulated network attachments in the centralized gateway.
One area impacted is the regulation and certification required for attachment to particular WANs or switched networks. Examples of such regulation include various software timeout and frequency limit requirements for call activities, as well as hardware management schemes. Presently, the workstation software applications should be separately updated according to the periodically-issued CCITT recommendations and separately certified.
In addition, the workstation software applications must be aware of the types of modems attached to the gateway WAN ports, and should replicate specific software support to take advantage of distinct features for these various devices. Because these protocols cannot be implemented at the central gateway, manual configuration steps in the attachment process across all of the workstations are often required.
In order to emulate heterogeneity in systems without RPCs, translation mechanisms are also required to support incompatible data representations (e.g., big and little endian formats) and character sets (e.g., ASCII and various EBCDIC code pages) between the LAN workstations, the gateway and/or the modems. For example, character set support in the Novell-based LAN gateway mechanism is restricted to ASCII, and the word widths of the device driver interfaces are fixed.
While the current approach of redirecting the LAN device driver facilitates relatively fast single-message transfers across the LAN, this direct access also results in monopolization of these driver resources for effecting and maintaining a switched communications link for certain users while denying access to others.